Software implementation of cryptographic building blocks may be insecure in a white box threat model where an attacker can control the execution process of the corresponding cryptographic operations. The attacker can easily lift the secret key from memory by just observing the operations acting on the secret key. For example, the attacker can learn the secret key of an AES (Advanced Encryption Standard) software implementation by observing the execution of the Key Schedule algorithm.
Certain constructions of the AES algorithm attempt to keep an attacker who has control of the cryptographic execution process from finding the secret key used in the execution process. However, such constructions usually are based on embedding securities using table lookups and masked data. As a result, there is a need for knowing a secure key value at the compilation time, or at least to derive the tables from the original key in a secure environment.
However, many cryptographic based applications, such as DRM (digital right management) applications may be associated with secure keys which are not available at the compilation time. For example, dynamically generated session keys and/or personal security keys associated with different users may only be available at runtime. Furthermore, embedding or storing multiple keys to be used in an application may require excessive storage resources.
Therefore, traditional implementations of cryptographic operations may be susceptible to attacks from attackers who have control over execution of the cryptographic operations.